-
-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Force Upload Support #281
Conversation
return 89; | ||
default: | ||
} | ||
break; | ||
default: | ||
throw new Error(`unhandled job type: ${jobType}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why CheckTarget is not handled here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think CheckTarget will be initiated on its own, but part of another flow like "Build & Flash" to check the target before any action is performed, so it doesn't need to have its own progress bar logic, although that doesn't currently work either, see my comment on the BuildJobType. If you think it would be useful to be a standalone action a user can take, I can add logic for it here.
) { | ||
let pioTarget = 'upload'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have commented about BuildJobType
usage in FirmwareBuilder
.
src/ui/gql/generated/types.ts
Outdated
@@ -309,6 +310,8 @@ export type BuildFlashFirmwareInput = { | |||
export enum BuildJobType { | |||
Build = 'Build', | |||
BuildAndFlash = 'BuildAndFlash', | |||
ForceFlash = 'ForceFlash', | |||
CheckTarget = 'CheckTarget', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you actually use BuildJobType.CheckTarget
anywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, CheckTarget is not currently being used. I attempted to use it to check the target before performing the actual build and flash, but unfortunately it is not very useful for that purpose because it causes the device to reboot and be disconnected from WIFI, which messes up the flashing process. I left the job type in the code in case we want to use it for something in the future, but it can be removed.
@@ -3,6 +3,8 @@ import { registerEnumType } from 'type-graphql'; | |||
enum BuildJobType { | |||
Build = 'Build', | |||
BuildAndFlash = 'BuildAndFlash', | |||
ForceFlash = 'ForceFlash', | |||
CheckTarget = 'CheckTarget', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this one used anywhere?
Hey guys, I was wondering if there was anything I could do to assist from the ExpressLRS build side. I could wrap all the calls and capture our exit code and maybe a message as well to a JSON file? I'm here for you if you need something from the build side. Sucks that there's no way to get an actual errorno back from PIO. |
I am parsing the error code out of the stderr output text, which works fine for the current purpose and can handle additional status codes as well, as long as the format remains the same. I don't know if writing/reading it from a file would provide any additional benefit over parsing it out of the output text at this time, but might be useful in the future for passing other information. Certainly open to ideas. |
Awesome! I just thought I'd offer to make sure you knew I was available to help if there was something that was blocking you. |
Closes #250